Computer systems and applications have reached almost every market on a global scale. As a result, vast sums of money are spent in researching and developing new applications and programs. Typically, these applications are written in a computer language selected by a software developer or by a group of software developers.
A trend among software developers has been toward use of object-oriented programming (“OOP”) languages. Two major categories of OOP languages are (1) systems programming languages, which are generally unmanaged and natively compiled and, in turn, executed natively; and (2) productivity-oriented business application programming languages, which are generally managed and compiled to non-native bytecodes or a non-native intermediate language (“IL”) and, in turn, executed non-natively by a managed runtime environment or virtual machine.
Systems programming languages are typically used for developing performance critical applications, operating systems, operating environments, operating system specific applications, managed runtime environments and virtual machines, embedded systems, and hardware specific software, such as for instance, device drivers. Systems programming languages are generally lower-level languages which offer finer control over the run-time execution of applications. Systems programming languages include, for instance but are not limited to C and C++.
Productivity-oriented business application languages are typically used for developing applications for electronic commerce, wireless devices, multimedia devices and platforms, accessing databases, web applications, and other business-related needs. Productivity-oriented business application languages are generally higher-level languages which offer greater programmer productivity and increased reliability during the run-time execution of applications. Business application languages include, for instance but are not limited to Java® and C♯ (pronounced, “C-Sharp”). These however, are just a few of the many OOP languages that may be utilized in generating applications.
Traditionally, software developers choose one computer language for systems programming and another for business applications programming. In doing so, however, they must make sacrifices and accept the tradeoffs of the selected language. The application, design methodology, and business model may all factor into the choice of programming language used for a particular application.
For instance, C++ is typically viewed as an advantageous language for creating large-scale applications, whereas Java is typically viewed as optimized for the distribution of program objects in a network such as the Internet. Java is generally considered a higher level language than C++, that is, closer to the actual business application. As a result, many programmers prefer to write programs in Java because it is generally considered an easier language to use than C++.
Another advantage Java provides is that Java objects cannot contain references to data external to themselves or other known objects. This ensures that an instruction input by a programmer cannot contain an address of data storage in another application or in the operating system itself, either of which could cause the program and possibly even the operating system to terminate or crash. In addition, Java utilizes a virtual machine that makes a number of checks on each object to ensure integrity. This results in a finished application that is not prone to low-level memory errors and requires considerably less debugging. C++ on the other hand does not have these safety functions such that a programmer may inadvertently or maliciously cause problems with the operating system. In addition, many of the computer viruses seen today exploit this characteristic of C++ to cause widespread computer problems. Many of these problems could be avoided by utilizing Java because of the built-in safety checks and balances inherent to the language.
Alternatively, there are some distinct advantages associated with C++ as opposed to Java. For instance, C++ is generally considered a higher performance language than Java. Once an application is written in C++, it may be compiled to native code or machine code, as opposed to Java, which is typically compiled into bytecode. As a result, unlike Java, a program compiled into native code does not need to operate with a virtual machine, which results in increased application performance. Another advantage to compiling a program to native code is that it is very difficult to derive the C++ source code from the native code, whereas it is a fairly simple matter to derive the Java source code from the compiled bytecode. Therefore, C++ can provide greater protection for a company's intellectual property.
In view of the forgoing, there is an inherent tension between using Java and using C++. Many programmers would prefer to write programs in Java, however many companies want their end product to be completed in C++ so that it may be compiled into native code. However, companies also recognize the benefits of using Java, realizing that it may be a faster and less expensive way to get new products and services to market. This is because Java is generally considered an easier language to use and also because of the greatly reduced debugging time associated with new applications.
Historically it has been very difficult or nearly impossible to convert a program written in C++ to Java and/or vice versa. To do so requires manual porting, which is generally labor intensive, error prone, and requires extensive re-testing.
To address these issues and minimize the differences between computer languages, a number of existing systems have tried a number of approaches. These include for instance: (1) cross-language interoperability layers and object mapping mechanisms; (2) native compilers for traditionally non-natively compiled languages; (3) programs which convert or migrate computer programs from one language to another language; and (4) programs which translate computer programs between different computer languages. None of these approaches, however, have provided an acceptable solution.
For instance, one approach taken is cross-language interoperability layers and object mapping mechanisms including the Sun Microsystems® Java Native Interface™ (JNI), the Microsoft® Common Object Model™ (COM), and the Object Management Group® (OMG) Common Object Request Broker Architecture™ (CORBA). Such solutions are generally suited for integrating two or more different computer languages and operating environments. However, they do not eliminate the need for middleware, such as virtual machines, managed runtime environments, and object request brokers (ORBs), but instead increase dependence on these. This dependence make these solutions unsuitable for demanding low-level systems programming for developing for instance, operating systems, virtual machines, and embedded systems.
A second approach taken includes native compilers for traditionally non-natively compiled languages including, for instance, the GNU® Compiler for Java (GCJ) and the Excelsior JET. The GNU Compiler for Java (GCJ) is a free (open source) software project and is disclosed in U.S. Pat. No. 6,110,226. These products compile Java source code or Java bytecode, a platform-independent intermediate language, to native binary executables. The GCJ compiler may generate native binary executables, which do not require a virtual machine to execute program, so long as the compiled Java program does not make use of Java classes or objects, which are externally referenced or otherwise not natively compiled. In the latter case, the compiled native binary executable requires an internal (statically-linked) or external (dynamically-linked) virtual machine, which suffers from the same drawbacks as cross-language interoperability layers and object mapping mechanisms. Alternatively, Excelsior JET for instance, generates native binary executables that generally depend on the presence of a virtual machine on the client system in order to run. However, these requirements carry the same drawbacks as common cross-language interoperability layers and therefore negate most of the benefits of native compilers.
While the GCJ compiler does support interoperability with C++ through CNI (Cygnus® Native Interface), this means of interoperability however, is effectively limited to the GNU C++ compiler. GCJ does not support interoperability with leading platform-specific C++ compilers, such as Microsoft Visual C++® for Microsoft Windows® operating system, nor does it support the industry-standard JNI to interoperate with leading Java virtual machines. Additionally, native compilers do not translate source code to another computer language, so they do not inherently benefit from wealth of available software development tools, such as compilers, linkers, optimizers, and debuggers, or features of other popular computer languages, such as C++.
A third approach has been to convert or migrate source code in one computer language to another computer language. This approach is disclosed in U.S. Pat. No. 6,453,464 (“the '464 patent”). This approach is directed toward migrating source code from an aging computer language, such as for instance COBOL, to an OOP language, such as Java. However, the resulting translated source code does not fully preserve the style and spirit of the original source code, is not easily human-readable, and does not support translation back to the original language. Therefore, the system disclosed in the '464 patent cannot be used for bi-directional translation between OOP languages to combine the best features of both languages.
A fourth approach taken has included computer language-to-computer language translation. Existing translators include Toba, C2J, and J2C, among others. These solutions, however, have severe limitations of their respective design and implementation. For instance, they fail to: manage objects exactly like the original language, manage arrays exactly like the original language, maintain the same high-level of thread safety characteristic in the original language, and support the full breadth of features of the original language. Additionally, none of these approaches support nor addresses bi-directional translation. Still further, these one-way translation approaches generally require translation of the entire application at one time, rather than providing for translation of only a file or a portion of a file.
What is desired then is a computer language translation system that accurately and reliably translates source code between divergent computer languages.
It is also desired to provide a computer language translation system that accurately and reliably translates source code between OOP languages.
It is further desired to provide a computer language translation system that may be coupled with associated software libraries and accurately and reliably translate source codes between higher-level productivity-oriented business application programming languages and systems programming languages.
It is still further desired to provide a bi-directional computer language translation system that may accurately and reliably translate source code from a higher-level productivity-oriented business application programming language to a systems programming language and back again.
It is yet further desired to provide a computer language translation system that is usable with multiple computing platforms, operating systems, and operating environments.
It is also desired to provide a computer language translation system that provides deterministic automated object management without a garbage collector in order to be suitable for embedded systems.
It is still further desired to provide a computer language translation system that may utilize industry-standard compiler tools, such as for instance, ANSI® C++ compilers.
It is yet further desired to provide a computer language translation system that will be virtual machine agnostic, specifically, that will be able to operate without a virtual machine, or conversely, if desired, able to interoperate with an industry standard virtual machine.
It is still further desired to provide a computer language translation system that adheres to industry standards for cross-language interoperability, such as JNI for interoperability between Java environments and C++ environments.
It is yet further desired to provide a computer language translation system that may be utilized to translate only a portion of the source code to be translated.